Date: Wed, 16 Jun 93 04:30:13 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V93 #155 To: tcp-group-digest TCP-Group Digest Wed, 16 Jun 93 Volume 93 : Issue 155 Today's Topics: bug in pktdrvr.c Change to telnet.c; terminal type negotiation Digital Audio (CVSD, CODEC) digital voice Followup to "Change to telnet.c;..." WAMPES patches Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Tue, 15 Jun 1993 22:35:56 EDT From: "Russell Nelson" Subject: bug in pktdrvr.c To: tcp-group@ucsd.edu In pktdrvr.c:pk_attach(), argv[3] is not used. This is the parameter that controls the maximum number of packets allowed on the transmit queue. Not only that, but a corresponding parameter is needed for the receive queue. The kodiak16 packet driver happily crashes NOS when it upcalls too many packets without giving NOS enough time to process them. NOS will happily suck up 80K to hold receive buffers. The humorous thing is that when you stop pinging it, it processes all the receive buffers and sends out a bunch of responses. This bug is present in all versions of NOS that use an unmodified pktdrvr.c. -- -russ What canst *thou* say? Crynwr Software Crynwr Software sells packet driver support. 11 Grant St. 315-268-1925 Voice | LPF member - ask me about Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do. ------------------------------ Date: Tue, 15 Jun 93 02:31:54 -0700 From: "Dana H. Myers" Subject: Change to telnet.c; terminal type negotiation To: tcp-group@ucsd.edu I made telnet able to negotiate term type with the the remote server; I set a DOS environment variable called 'TERM' (what else?) and I use NNANSI, with a NNANSI terminfo record at the server. The code is a little hacky and is in telnet.h and telnet.c; anyone interested? I also found what may be a small bug in telnet.c; it seems the count options (NOPTIONS) is one less than it should be. This could cause corruption of memory in some cases. Dana ------------------------------ Date: Tue, 15 Jun 1993 18:29:23 -0500 (CDT) From: S. R. Sampson Subject: Digital Audio (CVSD, CODEC) To: clint@uugate.aim.utah.edu Well I don't have any CVSD information, other than I found them very expensive relative to CODEC. I got some samples from a National Semiconductor, Richardson, Texas (214) 234-3811. The first samples were the TP3051 Parallel Interface CODEC/Filter COMBO(tm), and the second was the TP3058 Microprocessor Interface COMBO. After playing with the 3051 I found it was a clocking nightmare, and designed for the TP3155 Time Slot Assignment chip (which is interesting for multiplexing several channels as you would like to do). You'd probably want to use the Serial Interface version rather than the parallel. The 3058 is made for a micro and the only clock circuit would be a 1.024 MHz clock split to go to both the 3058 CLK pin, and through a divide by 128 (CMOS 4024 chip) to the 3058 FS pin (Frame Sync). This causes the device to sample at 8 kHz. The book you want to design with is the: Telecommunications Databook If you're interested, it lists the Salt Lake sales office as (801) 261-5402. In case you want to get the book, you might try there first, then Texas. I asked and received 2 samples of the chips, and they rooted and found me a book. This was a couple of years ago. This provides me with one voice spectrum (200 - 3400 Hz) 8 bit u-law sample every 125 usec. I can't help you with compression however, as I find Vocoders are quite expensive and source code unavailable for do-it-yourselfers (I mean I haven't found any, but some college probably has tons of code laying around). So this would require 64 kbps (8 bits x 8000) telco speed in the raw, which is quite a bandwidth. Vocoders of 2400 don't sound very good (well the STU-III at 2400 doesn't), while there seem to be more and more 9600 and better versions coming out. The best deal I've seen so far is: Skywave Electronics (613) 592-0908 They sell OEM Vocoders (3 inch square modules) with rates of 2.4, 4.8, 9.6, 14.4, or 16.0 kbps in the $1K range *each*. Maybe they have an Amateur Rate, but since it includes DSP (TI 320C25) it ain't going to be cheap. I wonder what regular Huffman compression would do to knock down the bandwidth? I say Huffman because I believe it can work on the fly, rather than buffer up like LZW. The cost of vocoders pretty much rules them out, so an alternative scheme is needed. Either that or knocking down the number of bits. Maybe I'm too concervative and you could just use the raw data broken into 1/2 second frames (512 bytes) with a header byte to identify the channel, and maybe a trailer word to CRC it (throw it on the floor and send NULLs to next link if error). With a 2 Mbps link you could probably have 8 channels of voice and an old 1 Mbps Ethernet or ARCnet circuit co-located on the same link frequency (I'm guessing with no experiance). I'll probably never use these things as I was developing a voice privacy module and used a cheaper design (TTL and old old old A/D) instead. You're welcome to them (Two TP3058 Parallel CODEC Chips), and you can probably get more from National, but this will at least let you evaluate them. --- Steve, N5OWK ------------------------------ Date: Tue, 15 Jun 93 23:16:02 -0600 From: Bdale Garbee Subject: digital voice To: ka7oei@uugate.wa7slg.ampr.org What we're preparing to play with in Colorado is the Qualcomm Q4400 variable rate vocoder chip, coupled with a DMTF decoder and a Motorola 145480 codec. The vocoder takes the 64kb PCM to/from the codec and reduces it to 4-9.6kb of variable-rate data. Qualcomm claims that no significant speach intelligibility is lost, but I haven't actually heard it run yet. The Q4400 includes a DTMF encoder on the PCM output, doing DTMF decode on the audio input before the codec seems like a win... couple it all with a housekeeping processor with a serial port and a board capable of very high quality speach at 9600 baud or less looks quite feasible. The only hitch is that VLSI division at Qualcomm is proud of the Q4400, to the tune of about $100 each in 100-unit quantities. Hopefully they'll reduce the price to something closer to what the silicon is worth eventually. In the meantime, this is not a game for the faint-of-wallet. I looked hard at CVSD for a while, but never got voice quality I liked at very low data rates. There are some nice, and cheap, parts from Motorola... if you have bandwidth to burn, there's certainly no cheaper way to go. Straight PCM codecs at 64kb are way too fat for the RF links around here. The QCELP encoding of the Q4400 looks "tres groovy". And it looks like it'll be fairly easy to write code to talk to it. Adding QCELP to the NVP protocol should be easy. We hope in the next year to at least be able to demonstrate a voice repeater link over WA4DSY 56kb modems using the Q4400 and friends talking the Network Voice Protocol (NVP) over UDP using Gracilis digital hardware. If anyone else is playing with this stuff, or even better has already reached nirvana, holler. Getting high bandwidth digital gear at voice repeater sites is likely to be much easier if I can "give away" digital voice crosslinks in exchange. :-) 73 - Bdale, N3EUA ------------------------------ Date: Tue, 15 Jun 93 02:34:27 -0700 From: "Dana H. Myers" Subject: Followup to "Change to telnet.c;..." To: tcp-group@ucsd.edu Heck, I didn't include my real mailing address... serves me right for staying up tool late hacking :-). If you are interested in the changes to make telnet set the term type on the server, mail me a note at "dana@locus.com". 73, Dana * Dana H. Myers KK6JQ | Views expressed here are * * (310) 337-5136 | mine and do not necessarily * * dana@locus.com DoD #466 | reflect those of my employer * * This Extra supports the abolition of the 13 and 20 WPM tests * * "Dammit Bones, spare me the lecture and give me the shot!" * ------------------------------ Date: Tue, 15 Jun 1993 13:52:46 -0700 From: Paul Traina Subject: WAMPES patches To: tcp-group@ucsd.edu [FYI: I sent this on to Dieter, but in case anyone else is interested, I would be happy to supply the diffs (they are to the 930614 release of WAMPES)] Dieter, Here are three sets of patches for WAMPES that you might wish to include in your next distribution. I have split them into separate context diffs to make it easier for you to decide which to take on: macII.diffs - improvements to the macII port (mainly switching from ndbm (which is broken under A/UX) to dbm) termserv.diffs - new functionality -- I actually have my TNC's connected to a terminal server, not directly to the computer. If you specifiy numbers in the unused BASE and IRQ fields in the 'attach' command, it will open up a TCP connection to a specific host/port. The user interface is not 'pretty' but it is functional. example: # attach tty0 at 9600bps (same as always) attach asy 0 0 kissui tty0 0 256 9600 # establish tcp/ip connection to 130.108.142.21 port 4006 and # call it "2m" attach asy 0x826c8e15 4006 kissui 2m 0 256 9600 # establish tcp/ip connection to 130.108.142.21 port 4007 and # call it "220" attach asy 0x826c8e15 4007 kissui 220 0 256 9600 ax25.diffs - new functionality -- I ported over all of the AX.25 broadcast and AX.25 call logging code. The AX.25 call logging code is NOT integrated into the autorouter on purpose. This is something different. This code is fully documented in the jnos manual. new commands: ax25 bcinterval - number of seconds between broadcasts ax25 bcport - ports to broadcast out on ax25 bc - another way to set broadcast port ax25 bctext - text to broadcast ax25 filter - filter AX.25 calls ax25 heard - show AX.25 stations heard ax25 hearddest - show AX.25 destinations heard ax25 hport - enable call logging on port ax25 hsize - size of logging buffer (# of calls) usage: # listen/log AX.25 stations on the 2m and 220 interfaces ax hport 2m on ax hport 220 on # brodcast ID every 3600 seconds on the 2m port (only) ax bcport 2m on ax bcinterval 3600 ax bctext "KC6TCN [44.4.0.30] WAMPES experiment, Palo Alto" ------------------------------ End of TCP-Group Digest V93 #155 ****************************** ******************************